\documentclass{article}
\usepackage[margin=4cm]{geometry}
\usepackage[parfill]{parskip}
\usepackage{lettrine}
\usepackage{titlepic}
\usepackage{graphicx}
\usepackage{appendix}
\usepackage{graphicx} % Allows including images
\usepackage{booktabs} % Allows the use of \toprule, \midrule and \bottomrule in tables

%\textwidth = 390pt

\title{Honeynet As A Service}
\author{Hanieh Bagheri, Todor Yakimov}
\date{\today}

\begin{document}
\maketitle

\begin{abstract}
With many advances in network threats, additional tiers of security are needed apart from the common security tools, such as firewall and Intrusion Detection System(IDS). One such tier can be using honeynets to gain some information about the existing security threats in the network. Although original honeynets were designed to run on real hardware machine, it is more effiecient to run honeypots on top of virtual machines. However, deploying honeynets is a time-consuming process and the obtained honeynet is still hard to maintain. In this research we focused on investigating the possibility of providing honeynet as a service, the appropriate architecure and different possibilities for implementation. 
\end{abstract}

\section{Introduction}

With many advances in network threats, additional tiers of security are needed apart from the common security tools, such as firewall and IDS. One such tier can be using honeynets to gain some information about the existing security threats in the network. In their essence, honeynets are designed to gather traces about the hackers that are capable of breaking into the network. In fact, the value of a honeynet lies in being probed, attacked, or compromised \cite{}. Providing emulated services or using real (and vulnerable) applications, a honeypot is able to deceive attackers to assume they are attacking and damaging the actual systems. In this way, the malicious behaviour can be detected, analyzed and captured and the results can be used to improve the security of the network. Although honeynets play an important role in improveing the security of a network, we should keep in mind that they are not a replacement for other seurity tiers, such as securitybest practices, security policies, firewalls, IDSes and patch management\cite{slides}. \\

The advantages of using honeynets is that it usually deals with suspicious and potentially malicious traffic. So compared to IDSes, it has to analyze less data and the provided information about the attackers are more valuable. Another advantage of a honeynet is capability of discovering new malwares. While monitoring an attacker behavior, a honeynet should be able to capture the used malware for further analisys.

Although honeynets are very useful for improving the security of a network, there are some disadvantages in using them: a honeynet can be a potential risk for the network, if it is not administered well. It also can be hard and time-consuming to maintain.

The original honeynets were designed to be implemented on physical machines. However, if an attacker accesses a honeynet node and successfully exploits the existing vulnerabilities, recovering that machine might be hard and time-consuming. With advances in virtualization technologies, some approaches are proposed to run honeynet software on virtual machines (VM) rather than the real hardware. This way, less hardware resources are needed. Moreover, in case of being exploited, the honeynet node can be easily recovered.

\subsection{Research objective}
In this research, we are interested in investigating the possibility of implementing a honeynet on a cloud environment. In this way, we would be able to offer honeynets as a service to the customers. We expect this kind of service make deploying honeynets easy, fast, cheap and easy to maintain. From the point of view of the service provider, the suggested model should be scalable, managable and economical. The goal of this research is proposing an architecture that satisfies both the customer and service provider requirements.


\subsection{Research Questions}
This project is mainly aimed to answer the following question:

\indent \emph{What is an appropriate infrastructure to be able to provide honeynet as a service? }
\\
\\
The sub-questions that will be answered in this report will be:
\begin{itemize}
 	\item Is it feasible to have honeynet as a service?
	\item What are the requirements?
	\item What components are needed?
	\item How can it be best implemented?
\end{itemize}

\section{Background work}
In terms of level of interaction between attacker and the system, there  are two types of honeypots: 
Low-Interaction honeypots:
A low-interaction honeypot only allows a limited interaction with the attacker. It emulates the services and systems for the attacker and reacts to malicious activities by running a script. As a result, the honeypot is not vulnerable and cannot be infected by the attacker [survey]. Low-interaction honeypots usually use vulnerability databases and also shellcode or exploit signature databases to detect malicious behaviours. Then they decode or emulate the used shellcode to derive the malware URL and download the malware. This model needs to update the honeynet databases regularely.

The most well-known members of this family are honeyd and Nepenthes. Honeyd is a small daemon which can create multiple virtual honeypots on a single machine. Different services like FTP, HTTP and SMTP can be emulated using honeyd. Honeyd [http://www.honeyd.org/faq.php] can also emulate the IP stacks of various operating systems by responding to Nmap and Xprobe packets. Nepenthes is another low-interaction honeypot, which is used for malware collection. It passively emulates known Windows vulnerabilities and downloads the payload when the attacker tries to exploit the vulnerability. Honeytrap and Kojoney are other examples of low-interaction honeypots.

High-interaction honeypots use real vulnerable operating systems and applications to be able to interact with the attacker. What we call honeynet is actually a network of high-interaction honeypots. High-interaction honeypots provide us with more detailed information about the attacker's activities. As we mentioned, high-interaction honeypots are nothing, but a vulnerable system. Therefore, we do not need an extra tool as the honeypot. We just need some data collection tools, such as Sebek [] Sebek is a kernel module installed on high-interaction honeynets for data collection. However, it is possible to use tools like Honeywall CDROM, which is a bootable CDROM, to build a high-interaction honeypot very quickly.

There are many tools available on the website of The Honeynet Project[footnote:http://www.honeynet.org/project]. These tools are mostly developed by the members of the project and are used for different purposes, such as providing a low-interaction honeypot, automated data analysis, malware collection and special-purpose tools for some applications and operating systems. The most well-known tools other than the ones mentioned above are Cuckoo, Dionaea, HIHAT and Qebek.

As disscussed above, low-interaction honeypots are easy to install and maintain. There is less risk in using them, because there is not an actual application behind them. However, the gathered information from low-interaction honeypots are very limited. Moreover, the honeypot software might have some vulnerabilities. \cite{slides}.
 
High-interaction honeypots are harder to install and maintain. There is more risk in implementing a high-interaction honeynet, because the attacker has a full controll over the honeypots. Moreover, it is very hard to deploy a large network of high-interaction honeypots, so honeynnets are hard to scale. On the other hand, a high-interactionhoneypot can gather more details about the attacker activities.

We want to have the best of two worlds: using real-systems (like high-interaction honeypots), but keep it simple, secure and scalable (like low-interaction honeypots)

Physical honeynets is a honeynet in which each honeynet is running on a separate physical machine. Moreover, the data collection and data analysis components are also running on different separate physical machines.
A virtual honeynet [] []  uses virtualization technologies to implement multiple honeypots on top of a single hardware machine. In this case, all the honeypots are running on a single machine, but the attacker has the impression of interacting with different machines.
There are some advantages in using virtual honeynets: the cost will reduce significantly, by using a single machine instead of multiple honeypot machines. Another advantage is easier management, because everything resided in a single machine. It is also a more secure approach, because the attacker is not interacting with actual machines, so there is no harm for honeypots in being exploited.

To the best of our knowledge, the only research about offering a honeypot as a service is done by M Balamurugan and B Sri Chitra Poornima []. They have proposed an architucture for implementation of a honeypot for servicesed and systems running in a cloud environment. In this solution, all the traffic goes through the Cloud Controller. The Cloud Controller contains a a Filter and Rediction Engine (FRE), which acts similar to a Network Intrusion Detection System (NIDS). It redirects the malicious traffic destined to real servers towards the honeynet.  The main disadvantages of this approach are the followings:
\begin{itemize}
    \item can just detect the attacks with a known signature inside the NIDS database
    \item is possible some non-malicious traffic being redirected to the honeynet without getting the real service
\end{itemize}

\section{Design}

\subsection{The ideal feautures}
In this research, we are interested in offering an appropriate solution in order to provide honeynet service for different networks (including both physical networks and cloud environments), which can solve the mentioned problems in the previous research []. In order to desig a good model, it is necessary to specify the desired features and goals: First, it should satisfy the definition of the term ''service''. It means the provided service should be \cite{LIABook}:
\begin{itemize}
	\item reliable
    \item scalable
    \item easy to monitor, maintain and support
\end{itemize}
If this these fundamental requirements are not satisfied, we cannot call the final product a service. Then, the designed model should cover all the requirements of a honeynet \cite{slides}. It means it should provide:
\begin{itemize}
	\item a controlled environment
	\item a high-interaction environment
	\item a data capture mechanism
    \item a data collection mechanism
    \item alerting mechanism?
\end{itemize}

\subsection{The proposed architecture}
After specifying the ideal features, it is possible to come up with a proper model, which covers these requirements, as much as possible. We assume there is a network that is interested in having a honeynet to be able to improve security of its demilitarized zone (DMZ). It expects to provide the Honeynet Service Provider (HSP) with some information via an interface and get a honeynet service easy and fast without need to much effort.

If one wants to deploy a honeynet inside the customer's DMZ, a good approach is assigning some IP addresses from the range used in the customer's network to the honeynet. In case an attacker intrudes into the DMZ and starts scanning all the IP addresses to find the open ports, he/she faces the honeypots, but considers them as production servers. Then, the honeynet can capture the attacker activities and detect, analyze and report the findings to the network administrators. Here, we used the same model. The difference is the honeynet is not inside the DMZ of customer.  but it resides inside a cloud environment. The HSP assigns some honeypots to the customer based on the provided information. These honeypots are assigned from a pool of virtual machine instances inside a cloud environment. Therefore, the attacker traffic should be redirected towards the cloud.

In order to do the mentioned activies, some basic components are needed. The proposed architecture in this research is consisted of the following components:
%\subsection{Client-side infrastructure}
\subsubsection{The fornt-end component}
The fornt-end component is a user interface, which is the start point for the service. This interface can be a simple web application. Using this interface, the customer lets the HSP know about the assigned IP addresses to the honeynet and the desired operating systems and applications to run on honeypot instances. Two different options can be offered about the the needed systems:
\begin{itemize}
    \item the customer can provide the names and versions of the needed system 
    \item The customer can give the HSP an image to run on honeypot instances.
\end{itemize}
After getting this informstion, the front-end component should initiate the requested VM instances. In the proposed model, we also need a component for controlling the the redirected traffic toward the honeypots (and the reverse traffic originated from honeypots toward the customer's network), which we call it ''monitor''. Upon receiving the service request from the customer, the front-end component should initiate a monitor. We will explain more about the monitor in section ?.

\subsubsection{The redirecting component}
The redirectng component is a facility for forwarding the traffic destined to honeynet IP addresses towards the monitor component. The crucial expectation from this component is to keep the source and destination of packets unchanged. However, to be able to send the traffic to the monitor, we also need to use the IP address of the monitor as the destination. There are different solutions to redirect the traffic, while still keeping the original source and destination addresses:
\begin{itemize}
	\item Iptables rules
    \item Switch configuration
    \item Virtual Private Network (VPN)
\end{itemize}

We will discuss the effects of using each solution in section ?.

\subsubsection{The honeypots}
As mentioned in section ?, in order to have a honeynet, we need to use high-interaction honeypots. A high-interaction honeypot should simulate the behaviour of the desired protocol. This goal can be best achieved using real applications and operating systems, which logs all the attacker activities. In our architecture, each honeypot is a VM instance, initiated by the front-end, based on the received information from the customer. Each honeypot runs a specific application or operating system, with known vulnerabilities. Running the last versions of applications and OSes can be helpful in finding 0day attacks. 


Using VM instances as honeypot is easier to deploy and cheaper in terms of the needed hardware. It is also easier and faster to recover the systems in case of being exploited by an attacker. 

\subsubsection{The monitor}
The monitor is the core component in our architecture. It is a piece of code, which starts to run on top of a VM instance, upon receiving the service request from the customer. Therefore, we should have a monitor per customer. However, different monitors can run on the same machine. It is worth mentioning that the suggested monitor component in this research in designed for detecting TCP attacks. An appropriate model can be designed for UDP attacks in a future work.

The monitor acts like a broker between the attacker and the honeypopts. It is responsible to receive connections from the attacker (forwarded by the redirecting module) and establishing a connection to the proper honeypot. This can be done using the NetfilterQueue library in Python (or the similar library in C). This library provides access to packets matched by an iptables rule in Linux \cite{website}. Here we should get access to SYN packets to be able to open the right port to the attacker. Then, we can open another port to the appropriate honeynet which is running a service matched by the opened port to the attacker. For example, if the attacker is trying to access port 80, we establish a connection to a honeypot running a web server application (which should be accessible via port 80).

One might suggest to use a simple proxy instead of the monitor, but it does not provide the desired functionalities. Using a proxy, we have to change the source address in the traffic. If we do so, the honeypots do not know about the IP address of the attacker, so the attacker detection process cannot be done properly.

After setting up the TCP connections, the attacker can communicate with the honeypots, but they are not directly connected. The monitor is in charge to exchange data between the two TCP connections. The benefit of this model is providing a controlled envirnment. All the traffic from attacker can just go the appropriate honeypot and the traffic from the honeypots can just come back to the monitor. Therefore, the attacker cannot directly access to a malware database from a honeypot to download a shellcode. If he/she decides to do so, the download request should be sent to the malware database via the monitor. Since it is a suspicious activity, this can be used as the malicious activity detection in the monitor. After detecting and logging the malicious activity, the monitor can still let the attacker to exploit the honeypot to gather more information about the attack. Since the honeypot activities are controlled by the monitor, it cannot be a threat to the outside world. In case of happening a serious problem for a honeypot, it can be easily recovered.


\subsubsection{The analysis module}
Honeypots should regularely send their log

\section{Conclusion}

\section{Future Work}
In this research, we mostly focused on designing the appropriate architecure for offering a honeynet as a service. Although we come up with a simple proof-of-concept implementation, to be able able to provide the real service, all the described modules should be fully implemented according to the suggested architecure. The components which need more work are the monitor and the redirecting component.

The suggested architecure is proposed to deal with TCP attacks. To improve the reserach aspect, one can improve the monitor component to make it handle both TCP and UDP attacks.

%Abbasi, Fahim H., and R. J. Harris. ''Experiences with a Generation III virtual Honeynet.'' Telecommunication Networks and Applications Conference (ATNAC), 2009 Australasian. IEEE, 2009

%Lanoy, Aaron, and Gordon W. Romney. ''A Virtual Honey Net as a Teaching Resource.'' Information Technology Based Higher Education and Training, 2006. ITHET'06. 7th International Conference on. IEEE, 2006.


\newpage

\begin{thebibliography}{2}

%\bibitem{MBJB}
%M. de Boer, J. Bosma, ''Discovering Path MTU black holes using RIPE Atlas", June 8 2012.
%http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

%\bibitem{RFC4443}
%A. Conta, S. Deering, M. Gupta,"Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", \emph{RFC 4443, 2006}

%\bibitem{RFC2181}
%R. Elz, R. Bush, "Clarifications to the DNS Specification", \emph{RFC 2181, 1997}

%\bibitem{RFC1191}
%J. Mogul, S. Deering, "Path MTU Discovery", \emph{RFC 1191, 1990}

%\bibitem{RFC_1981}
%J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6", \emph{RFC 1981, 1996}

%\bibitem{Gijs}
%G. van den Broek, R. van Rijswijk, A. Pras, A. Sperotto, "DNSSEC Meets the Real-World: Improving Response Deliverability", MSc.Thesis, University of Twente, The Netherlands.(Private communication) July 6th 2012 

%\bibitem{MAdns}
%M. Andrews, "DNS and UDP Fragmentation", \emph{draft-andrews-dnsext-udp-fragmentation-01, 2012}

%\bibitem{RIPE}
%V. Manojlovic, "RIPE Atlas 2012 Year in Review", 2013

%\bibitem{BCP38}
%P. Ferguson, D. Senie, "Network Ingress Filtering:Defeating Denial of Service Attacks which employ IP Source Address Spoofing", \emph{BCP38, 2000}

\end{thebibliography}


\end{document}










